home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 11⁄3⁄89 / 0028-Re USES problems-Nov89 < prev    next >
Encoding:
Text File  |  1989-11-03  |  2.4 KB  |  56 lines  |  [TEXT/GEOL]

  1. Item    5715992                         3-Nov-89        06:25
  2.  
  3. From:   NOR0042                         NOD Data Nostra
  4.  
  5. To:     SW0092                          SWD Administrator System AB, Sthlm
  6.  
  7. cc:     MACAPP.TECH$                    MacApp Technical
  8.  
  9. Sub:    RE- USES problems
  10.  
  11. Dear Kent,
  12.  
  13. I too have USES problems, but I think I can answer your question.
  14.  
  15. (1)  The way the USES clause works is that the INTERFACE part of the units used
  16. are scanned in the same order as they appear in the USES clause.
  17.  
  18. (2)  Pascal has the general principle that an identifier must be declared
  19. before it can be used.
  20.  
  21. So let us put (1) and (2) together.  If our unit refers to an identifier from
  22. another unit in our INTERFACE part, then because of (1), not only we, but all
  23. clients who USE us, also have to USE the unit which the identifier stems from,
  24. and because of (2) its name must be mentioned first.
  25.  
  26. If we restrict ourselves to mention the identifier in our IMPLEMENTATION part,
  27. our clients don't have to bother because only our INTERFACE part is read during
  28. their compilation.
  29.  
  30. That was an explanation, not a solution of problems, and I too would like to
  31. see some good advice and rules of thumb.  The above mentioned principles impose
  32. a tree-structure where procedures are high-level and low-level, and low-level
  33. procedures have no knowledge about their high-level clients.  This hierachial
  34. design is good in a procedurally oriented design, but is it necessarily true
  35. with objects?  Two objects which happen to know each other, directly or
  36. indirectly, should they be put in the same unit?  Or should we absolutely avoid
  37. such circular references?  I struggle to make good object oriented design, and
  38. often I perceive the strict USES principles as a severe limitation.
  39.  
  40. The problem arises frequently when an object has another object as a field and
  41. therefore needs its classname in the INTERFACE part.  An alternative is to give
  42. the field a more general type from which it inherits and typecast when new
  43. methods are called because "we know" that these methods are present.  But
  44. object casting should not be done regularly, or should it?
  45.  
  46. There are also some technical questions involved.  In a complicated program the
  47. compiler (3.0) may refuse to recognize some objects, but when I MABuild with
  48. "-Pascal -clean" option, everything works fine, but slow of course, as the
  49. compiler has to read the text directly instead of symbol tables.
  50.  
  51.     Sigmund Tveit
  52.     Data Nostra A/S
  53.     Oslo, Norway
  54.  
  55.  
  56.